# HP OpenView Service Desk

## version 4.5
remote updater

November 2004

© Copyright 2004 Hewlett-Packard Development Company, L.P.

## Contents:

Last-minute information
Introduction
Getting Started
Known errors and limitations
Test cases
Frequently asked questions (FAQ)
Trouble shooting
External links

## LAST-MINUTE INFORMATION

Clients updated to Service Pack 15 by remote updater will pop up with the "java.lang.NullPointerException" text when trying to open the administrator console. File AdminConsole.atb should be copied manually to <client installed directory>\repo folder.
This issue is fixed in Service Pack 16 which means the AdminConsole.atb will be updated automatically by remote updater.
See ITSM007823 for more information.

## INTRODUCTION

Whenever a new hot fix or service pack is released with fixes and / or features for the Service Desk console client, it has to be installed on every end user machine. In large companies different IT departments can cause delays in the distribution of a simple hot fix which usually updates no more than a few files and currently requires some sort of third party distribution mechanism or simply manually copying of the file in order to get the hot fix to the end user machine.
For service packs, the situation is similar, although it has to be said that because of the size of the service pack, the delay of installation is usually because of the test effort required to ensure that the production system can be upgraded without problems. Currently, the risk that a hot fix is required to resolve potential problems in the production environment fuels the need to perform extra testing on the service pack and the knowledge that a hot fix cannot be easily applied on all end user machines delays the implementation of a service pack even more.

Because customers are experiencing numerous difficulties keeping up with the latest fixes on the Service Desk product, it happens that when a customer is ready to upgrade to a service pack, a newer service pack is already available. This is because the implementation time between a service pack and the release of the next service pack is greater. For a customer this means that fixes for potential problems are already available, but it is practically impossible to apply a newer service pack as they just implemented a previous one. The customer then requests hot fixes for the most urgent problems, in order to bridge the gap between the release of the service pack and the implementation of that service pack.
Currently the level of effort required when distributing a hot fix in a customer environment depends on the Service Desk component that the hot fix is for. If the hot fix is only required on the application server, there is no real problem as the amount of application servers is limited, but if the hot fix is required on all the clients, the customers have great difficulties because they have to get the ‘hotfix.jar’ to all the client machines, of which there can be thousands. Although this can be done by copying the file, via email, or using a software distribution system, the process can be time consuming and above all error prone.

The addition of a mechanism that provides easier distribution of a hot fix and a service pack would greatly reduce the impact and existence of the above mentioned problems. Further more, it is now impossible to forget to copy or install a hot fix to the correct location, and thus ensuring that all users

## GETTING STARTED

Service Desk 4.5 will be extended in a way that enables customers to easily distribute and remove hot fixes on their clients in their environment. The main idea is that during the start up of a client console, a check is made at the application server to see if there is a new hot fix that needs to be distributed, and if so, to transfer this hot fix to the client and install it automatically.
An almost similar rule applies to client side service packs: they are downloaded automatically as soon as a new service pack is available and installed on the application server if the feature has been activated that is. If so, the current mechanism where users receive a notification screen that their version is out of date and need to upgrade by clicking on the hyperlink, is replaced by a notifation that a new update has been received and that the application will be restarted. However, only the actual client servicepack.jar is remote updatable. Other files such as batch-files and other jars are beyond the scope of this new feature. This means that end users that require all Service Desk functionality, like export and import for example, will have to install the normal client patch, see known errors and limitations for more details.

The remote updater, as the feature is called, is not a replacement for the current patch mechanism, but coexists besides it. Customer that do not want to use the feature, can still use the current patch mechanism available.

When the remote updater feature is activated, either for service packs, hot fixes or both, and a new update is available and has been downloaded to the clients local data folder, the Java virtual machine (Microsoft jview or wjview) will be "restarted". The current Java virtual machine is shutdown but just before that, a new Java virtual machine process (the client) is launched with the new update included in the class path. This is done to simulate dynamic class loading; after a Java virtual machine restart, all classes are reloaded with their newer versions if available. Dynamic class loading is a great feature of Java but unfortunately is part of the Sun Java 1.2 and higher versions. As Microsoft Java, which is still used for the client, is only Sun Java version 1.1.4 compliant, we cannot use the Sun Java 1.2 or higher features. Dynamic class loading was therefore not an option.
A hot fix does not have a version, and therefore an MD5 checksum is used to determine if the hot fix, if present, on the client is the same as the one installed on the application server. This way a hot fix can be overwritten with a different version, as long as the byte code of the file differs. To remove a hot fix, it is sufficient to uncheck the hot fix checkbox in Tools > System > hp OpenView Service Desk > General Settings > Remote Updater. This will not remove the existing hot fix file on the server, but will tell new clients that connect to the application server to remove an existing hot fix if present.

The first addition to Service Desk is the addition of an extra tab in Tools > System > hp OpenView Service Desk > General Settings:

In this tab you will be able to activate or deactivate the remote updater functionality for a hot fix and / or service pack.

Note. The first time you activate either the service pack or hot fix by checking the relevant check box, you will not get detailed information for the service pack or hot fix that is available, if any that is. When you activate the service pack functionality and close and reopen the Tools > System > hp OpenView Service Desk > General Settings screen you will see more detailed information about the hot fix (resolved defect numbers) or service pack (version information). This is shown below with an example for the service pack. Note that for the hot fix you will have to restart your client.

When the application server is updated with a service pack using the existing patch mechanism, an additional file, the service pack jar file for the client, is copied to the <server home>/repo folder. This file will be named servicepack-client.jar and is overwritten by a new client service pack jar file with every service pack that is released. When a new service pack is installed, the hot fix functionality is automatically disabled because in most cases, either the hot fix solution has been included in the service pack, or a new hot fix has to be provided by support because the hot fix needs to be recreated to work for that service pack.

Enabling the service pack
Enabling the service pack simply means that when a new service pack is released any client that connects to the application server and that has a lower version than the application server will receive the servicepack.jar for the client and restart. The application server service pack contains a servicepack-client.jar that is placed in the <application server home>/repo folder. In more detail this thus means that when clients connect the application server will send this servicepack-client.jar to the client if applicable, after which the client will save the file as servicepack.jar in the user data folder and finally the client will be restarted.

NOTE. The new service pack needs to be installed using the existing patch mechanism on the application server(s) and other Service Desk components that either cannot use the remote updater functionality (e.g. agent, service pages, etc.) or require additional client updates because for example import and export features are used on that client.

Enabling the hot fix
Enabling the hot fix will initially do nothing as no hot fix has been selected. This can be done be clicking the Install button and selecting the hot fix that needs to be distributed. The hot fix to be selected should be available on the client system that performs the remote updater administration. However, this is only required when initially installing or uploading the hot fix. This basically means that when the administrator selects a hot fix for distribution this hot fix is copied from the clients system to the application server that the client is connected to. The hot fix is stored on the application server in the <application server home>/repo folder so it is important for the application server process to be able to have write access for the <application server home>/repo folder.

As soon as a hot fix is uploaded to an application server this application server sends a message to other active application servers that a new hot fix is available. These application servers then retrieve that hot fix from the application server that send the message. Application server that are started after a hot fix has been distributed do not have the hot fix on startup, but as soon as a client connects to that application server, the application server requests the hot fix from other active application servers and sends that hot fix to the client as well as stores it on it's local file system.

When clients receive a new hot fix or a service pack, the following screen is shown:

Clicking the Cancel button means that the client is closed but not restarted.

When both the service pack and hot fix remote update functionality have been enabled, the screen will look something like the one below:

Enabling both the service pack and hot fix means that all clients that are not yet upgraded to that service pack, and that also do not have that hot fix, will receive first the hot fix after which the client is automatically restarted, and then after the version check with the application server, the service pack, after which obviously the client is again automatically restarted. This basically means that depending on which service pack the client is on, and which hot fix the client currently has, the application could be restarted automatically a couple times, because there is also the possibility of locked files. The overall time to startup a client however does not increase dramatically, except perhaps in the event of a service pack upgrade, because the version check is performed at a later stage during the logon sequence.

It will be possible only to install one hot fix at a time. A new hot fix will replace the current hot fix on a clients system.

Uninstalling a service pack
By clearing the service pack Enabled check box the application server no longer returns the servicepack-client.jar to client but as was in the past an incorrect version message. The client will then display the normal Upgrade Software message dialog as shown below:

Note. If the client is then upgraded using the normal msp patch mechanism and the client is started up, the servicepack.jar in the user data folder is automatically removed.

Uninstalling a hot fix
By clearing the hot fix Enabled check box the application server will notify all application servers that the hot fix needs to be removed from all newly connecting clients if applicable. A message dialog will pop up to indicate that the hot fix will be removed for all clients! See the screenshot below:

As soon as a client connects to an application server, a check is made to see if a hot fix is available. The application server responds that hot fixes should not be used after which the client removes an existing hot fix and restarts or simply continues the startup depending on whether a hot fix exists on the client.

NOTE. The hot fix will not be removed from the <application server home>/repo folder. Be sure to check the <application server home>/repo folder on all application servers when applying numerous hot fixes because of potential disk space problems!

## KNOWN ERRORS OR LIMITATIONS

Overall
As mentioned before only the actual client servicepack.jar is remote updatable. Other files are beyond the scope of this new feature. This means that end users that require all Service Desk functionality, like export and import for example, will have to install the normal client patch. A choice had to be made for the supported functionality this should be sufficient for a large (>95%) portion of the client install base. Client functionality that works with the remote updater is:

- client
- sd_dataform
- client accounts setting
- client support tool

Privilege required
Write access for <service desk user data folder> is required to have the client updated via remote updater.

Existing client hotfixes
If a non-empty hot fix (a hot fix with additional files besides a manifest file) is already present in the <client home>\lib folder, the existing hot fix will be used instead of the hot fix that has been updated through the remote updater mechanism.

Windows 98
This feature is not supported for clients running on Windows 98 (or even lower). A short survey showed that most customers will have migrated to a newer Windows version. On top of that, technical difficulties where encountered with running command line commands on Windows 98.
Command line commands may not exceed 128 characters whereas commands in batch-files may not exceed 1024 characters. Starting the client console using jview or wjview requires the class path to be specified and even if the relative paths are used the command will still exceed 128 characters. Also, running jview or wjview from a batch-file will popup a DOS-box which will not disappear after the process has terminated.

Application server
The application server process is required to have write access for the <application server home>/repo folder in order to be able to store hot fix files.

Hot fixes will not be removed from the <application server home>/repo folder. Be sure to check the <application server home>/repo folder on all application servers when applying numerous hot fixes because of potential disk space problems!

## TEST CASES

Please refer to the test cases document containing all test cases that have been used during testing this feature.

## FREQUENTLY ASKED QUESTIONS

Please refer to the frequently asked question document.

## TROUBLE SHOOTING

Database
The checks that the application server(s) perform during startup and runtime with regard to retrieving new service pack or hot fix information are actually queries to the database. The database contains new information about the status of the remote updater, whether it is enabled or not, and the names of the files that are available. To view this information in the database the following queries can be used:

Retrieve the hot fix name:
select * from REP_GENERAL_SETTINGS
where SET_OID = 281478295847001;

Retrieve the hot fix checksum:
select * from REP_GENERAL_SETTINGS
where SET_OID = 281478297026637;

Retrieve the hot fix Enabled status:
select * from REP_GENERAL_SETTINGS
where SET_OID = 281478295846999;

Retrieve the service pack name:
select * from REP_GENERAL_SETTINGS
where SET_OID = 281478295847002;

Retrieve the service pack Enabled status:
select * from REP_GENERAL_SETTINGS
where SET_OID = 281478295847000;

Client
If you have problems starting up the client it is possible to run the client with the -CLEARUPDATES option. This option will remove an existing hot fix and / or service pack from the user data folder and then proceed with the startup. Any updates available will then be retrieved from the application server. For example start the sd_client.bat from the <Service Desk client home>/bin folder using:
sd_client.bat -CLEARUPDATES

Application server
In the event problems arise with either a hot fix, a service pack or both, and that cannot be resolved with starting up the client and disable the remote updater, the following database SQL statements can be used to disable the remote updater functionality:
Disable service pack
update REP_GENERAL_SETTINGS set SET_VALUE = 0 where SET_OID = 281478295847000;

Disable hot fix:
update REP_GENERAL_SETTINGS set SET_VALUE = 0 where SET_OID = 281478295846999;

## EXTERNAL LINKS

MD5: [The MD5 algorithm] takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA. Please refer to the rfc1321.txt specification for more details.